Skip to content

feat(a11y): automatically set accessible prop with role prop#57633

Open
mdjastrzebski wants to merge 3 commits into
react:mainfrom
mdjastrzebski:feat/automatic-accessible-with-role-prop
Open

feat(a11y): automatically set accessible prop with role prop#57633
mdjastrzebski wants to merge 3 commits into
react:mainfrom
mdjastrzebski:feat/automatic-accessible-with-role-prop

Conversation

@mdjastrzebski

@mdjastrzebski mdjastrzebski commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Summary:

Setting role prop (except none/presentation) automatically sets accessible prop on View and Image. This aligns web behavior when setting role attribute is enough to add the element into accessibility tree.

This aligns also with Image alt web-compat prop which also enables accessible when set.

The change skips Text, TextInput, etc as they are implicitly members of accessibility tree by default.

This change also intentionally skips accessibilityRole as legacy, non-web version.

This also helps when using React Strict DOM, as it exposes role prop, but does not expose accessible prop, hence setting role on h.div basically has no effect. I think this changes is better suited for RN repo though.

Changelog:

[GENERAL] [CHANGED] Automatically set acessible prop when role prop is set (except none/presenation)

Test Plan:

Added relevant Fantom tests.

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jul 22, 2026
@facebook-github-tools facebook-github-tools Bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Jul 22, 2026
@mdjastrzebski mdjastrzebski changed the title feat(a11y): automatic accessible with role prop feat(a11y): automatically set accessible prop with role prop Jul 22, 2026
@javache

javache commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

This seems reasonable, but is there any chance we can do this on the native side instead? We should avoid post-processing props in JS for perf reasons.

@mdjastrzebski

Copy link
Copy Markdown
Contributor Author

@javache I did some research and it looks like C++ calculation would be fine for iOS, but on Android we need to have duplicated logic in Kotlin since the ViewManagers use the original JS rawProps, not the C++ derived values. Props 2.0 would solve it but it's not enabled atm.

Hence, I would advise to keep it in JS right now, and migrate multiple prop calculation from JS to C++ as a unified effort when Props 2.0 is available on Android.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants